1. Field of the Invention
This invention relates to transaction processing systems, such as banking or retail transaction systems, and in particular, to associated transaction processing terminals and networks.
2. Description of Related Art
Transaction processing networks, such as banking and retail transaction networks, may commonly comprise one or more transaction terminals connected to a server. Typical transaction terminals may comprise automated teller machines (ATMs), retail point-of-sale (POS) terminals, general self-service terminals (SSTs), and transaction kiosks. Each terminal generally has a central processor, typically PC based, which controls the operation of the terminal, application flow and user interface presentation. Application software and files used by the application are typically stored on a hard disk or other mass storage device within the terminal. The terminal generally is connected to a server through a connection, which may be a high order communications link or a modem and telephone based link into the network. The server may access an information database (e.g., a “legacy host”) to assist in processing a transaction.
Numbers of other terminals, which may be of the same or of a different kind, may be connected in the transaction network. Simple client-server transactions may be conducted between a terminal and the host in order to obtain specific customer information used in the processing of a customer's transaction. In the case of an ATM the transaction may typically be a cash withdrawal or a balance request. In the case of a retail POS terminal a typical transaction may be a sale that makes use of price lookup.
A transaction terminal generally includes peripheral devices that are often very specific to the function of the terminal. Typical peripheral devices included in an ATM are a card reader, a cash dispenser, a receipt printer and a user interface (e.g., an encrypting keyboard and a display). Typical peripheral devices included in a POS terminal are a card reader, a bar code scanner, a receipt printer and a user interface (e.g., keyboard and display). Such peripheral devices are not all normally found on a general-purpose computer and must be incorporated both physically and electrically and be provided with appropriate control software. The serial and parallel ports associated with the central processor of a personal computer (“PC”) can be used to supply control signals to the peripheral devices. Alternatively, a proprietary communications system can be employed; for example, the communications system known as Serial Distributed Control (“SDC”) is used in ATMs manufactured by NCR Corporation. In either case, peripheral devices generally require some form of localized or embedded processing capability to conduct communications with the central processor and to implement its commands upon the device.
The above approach has a number of failings. The desired main task of a central processor is to present information, graphics and animation to the user. However, the processor has also been required to conduct control operations and possibly maintenance operations on the peripheral devices connected to it. Therefore either a larger processor may be required to obtain a given level of user interface performance or this performance may be adversely affected by the control operations of the processor on the peripheral devices.
Additionally, a terminal's peripheral devices have been configured to act as simple command processing systems, with all application control being conducted from the central processor. Peripheral processing capability was therefore not always well used, particularly when invoked in a start-stop manner.
Furthermore, when it was desired to change the control logic for a peripheral device this often could only be done by changing the ROM (read-only memory) parts on the device or else by loading new driver software through the central processor over the communications channel within the terminal. All applications software, peripheral device drivers and user interface files have commonly been held in a mass storage device within the terminal. Collectively the installed software many times comprised a large monolithic system, in effect a central program used to control the various aspects of the terminal operation, from the user interface presented to the control of the peripheral devices. The installed software further generally included the necessary application business logic and error handling routines. In order to upgrade the software associated with any individual function or module it was thus often necessary to install a new suite of program files onto the terminal's mass storage device and to otherwise disrupt the terminal's operation for software maintenance. Particularly in the case of ATMs where security is a significant factor this could be an arduous task requiring secure disc build operations at each individual terminal.
While this type of software upgrade approach may be feasible, although cumbersome, for driver software in current use, it may not be practical for transaction terminals in the future, which may be required function in a much more dynamic manner, e.g., by dynamically changing their capabilities at transaction run time and not just at the start of day. Examples of this may arise in connection with the need to operate with so-called “smart” cards of various kinds.
Smart cards generally have built-in electronic processing and data storage facilities. Card readers for such cards may need to be able to both read from and write to different kinds of smart cards and to the underlying applications contained within those cards, and may thus be called upon to dynamically change their capabilities or manner of operation at run time. Smart card readers may thus be required to use different drivers or control logic dependent on the actual smart card that is inserted. There may also be a requirement to dynamically download new applications software for transfer from the terminal to various types of inserted smart cards. However, installing and maintaining various smart card reader drivers, control logic implementations and smart card applications may well put further strains on systems maintenance.
Printers may require the dynamic download of different graphics drivers to support various different graphics formats. Also, dispensers may not be limited to dispensing cash only but may be required to dispense other media such that alternative or additional control software may be called for at run time.
While application development tools are becoming available that may allow the developer to consider peripheral modules as functional components, maintenance issues will remain if application business logic and error handling facilities for these components are made to reside within a single central application program.